Subject: Locate search cleanup

From: "Roy Brabson (254-7332 (T/L 444))" <[email-masked]>
Date: Tue, 6 Jun 95 09:40:33 EDT

Dave, I've imbedded comments below.

Roy Brabson

-----------------------------------------------------------------------

> I have been looking at the description in the DS chapter of
> the handling of CP-CP session outage during a search procedure.
> On page 8-58 (of SC30-3422-3), it indicates that both sides
> of a CP-CP session outage send LOCATE(discard) such that the
> procedure is cleaned up in both directions.
>
> It is clear (I think :-)) that on the origin CP side, if the
> node detecting the outage is waiting for a reply, it can simply
> generate a complete -ve reply LOCATE(discard). This is because
> its parent CP is expecting a reply.
>
> However, for the case of the node detecting outage on the
> destination CP side, does it send a LOCATE rq or reply ? Also,
> how does it use the PCID modifier/search number ? Are they
> incremented, or does it use the same subprocedure identifier
> as it last received for the search procedure ?
> The later of course would require special checking in the
> collision detection test (ie a collision is allowed if a
> request and locate chain = discard).

A Locate(chain_flow,discard) will be sent to the child (ie,
toward the destination CP).  This will only be done if a Locate
chain is being maintained (i.e., a complete reply with the KEEP
indicator set has been received).  Note that this reply may be
received before or after the CP-SON occurs.

When sending the Locate(chain_flow,discard), the PCID modifier/search
number will be set to the same value that was received on the reply.
Neither will be incremented.  If they were, then the flow would be
seen as a new one by all DS's on downstream nodes.

> The same consideration is required on the origin CP side if
> the last thing it sent was a complete reply (keep). Since its
> parent is not expecting another reply, it is not clear what
> sort of LOCATE (rq/reply, and subprocedure identifier) is
> required.

Again, a Locate(chain_flow, discard) will be sent.  It will
use the same PCID modifier/search number that was sent on the
Locate(complete reply, keep).

> Also, does this cleanup logic apply on a broadcast search as
> well as a directed search ?

No, this cleanup logic only applies to a directed search where a
Locate chain is being maintained *after* a complete reply has been
returned to the search origin.  Such a Locate chain can only be
maintained on a directed search.

> Assuming answers to the above are that a rq is sent, would
> it be normal to send only a LOCATE GDS for the cleanup flow ?
> (ie no other GDSs in the search request.)

Yes, only send a Locate GDS variable.  The Locate should contain a
CV35 with sense code x'08900070'.

---

From: [email-masked] (Dave Finnie)
Date: Wed, 7 Jun 95 21:24:57 EST

Dario,

>  > Also, just to clarify - on a broadcast search, cleanup is never done ?
>  > So if the link between NN1 and NN2 dies, and NN1 is the parent of NN2
>  > in a search, then NN2 simply waits for its children to reply and 
>  > then discards knowledge of the search ?
>
>Never--you would never chase a broadcast search down (just picture a
>dog chasing its tail). Yup, that's one way of implementing it.

:-)

Totally agree. Just as many discards would be sent as replies, which
obviously isn't much of a cleanup ! I like to make sure of these things,
though.

Dave

---

From: [email-masked] (Dave Finnie)
Date: Thu, 8 Jun 95 07:47:37 EST

Roy,

OK. Thanks for the clarification.

Dave